Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.19%. Comparing base (cc31504) to head (be82424).
Report is 1 commits behind head on main.

@@           Coverage Diff           @@
##             main    #1106   +/-   ##
=======================================
  Coverage   71.19%   71.19%           
=======================================
  Files          64       64           
  Lines        4236     4236           
=======================================
  Hits         3016     3016           
  Misses       1220     1220           

datalab    Run #3251

Run Properties:   Passed #3251  •  0908366deb ℹ️: Merge be82424b4331661812ada11edb1556995a8f132b into cc31504bd12ad8e2a6b7e873f919...

Project	datalab
Branch Review	bc/filter-noblock
Run status	Passed #3251
Run duration	07m 48s
Commit	0908366deb ℹ️: Merge be82424b4331661812ada11edb1556995a8f132b into cc31504bd12ad8e2a6b7e873f919...
Committer	Ben Charmes
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	0
Skipped	0
Passing	501
View all changes introduced in this branch ↗︎

I haven't tried on this branch, but I was also noticing that "match any" seems to always match samples with 0 blocks. Is that easy to fix?

This is doing something a bit strange on my local instance, filtering for "match all" -> "no blocks" still leaves some entries that have blocks. Perhaps relatedly, on main and this PR, if I try to simply sort in ascending order by the blocks column, it starts with the entries with 1 block rather than 0.

Thank for the review @jdbocarsly & @ml-evs !

• For Josh, do you mean with "Math any" and the second dropdown empty ? (With just "any" and no blocks selected ?). If yes, now that we add "No blocks" in the dropdown, I guess it make sense that "Match any" also give sample with no block ? But yes, before, it should only have filter samples with blocks.
• I can't reproduce the first behaviour Matt describes with "match all -> no blocks"
• For the second behaviour you describe, it's probably because the box is empty (and doesn't have ‘0’) when there are no blocks. I can look for a way to change that

I'm going to take a closer look at all this!

Realised what is causing this behaviour: when you copy a sample that has blocks, the block is copied identically and then the API summary doesn't include it even though nblocks: 1 -- weird bug we need to fix